fix: emit diagnostic for non-type numeric literal suffix instead of panicking#9810
Open
fix: emit diagnostic for non-type numeric literal suffix instead of panicking#9810
Conversation
This was referenced Mar 31, 2026
Collaborator
Author
This stack of pull requests is managed by Graphite. Learn more about stacking. |
This was referenced Mar 31, 2026
|
This change is |
This was referenced Mar 31, 2026
eytan-starkware
requested changes
Mar 31, 2026
Contributor
eytan-starkware
left a comment
eytan-starkware
left a comment
There was a problem hiding this comment.
@eytan-starkware reviewed 2 files and all commit messages, and made 1 comment.
Reviewable status: all files reviewed, 1 unresolved discussion (waiting on orizi and TomerStarkware).
crates/cairo-lang-semantic/src/expr/test_data/literal line 36 at r1 (raw file):
//! > expected_diagnostics error[E2011]: Not a type.
Bad diagnostic
orizi
changed the base branch from
orizi/03-31-fix_macro_rule_missing_param_kind
to
graphite-base/9810
orizi
force-pushed
the
graphite-base/9810
branch
from
dbb21ea to
8dd8779
Compare
orizi
force-pushed
the
orizi/03-31-fix_non_type_numeric_literal_suffix
branch
from
fca4f70 to
3395304
Compare
orizi
commented
Apr 1, 2026
Collaborator
Author
orizi
left a comment
orizi
left a comment
There was a problem hiding this comment.
@orizi made 1 comment.
Reviewable status: all files reviewed, 1 unresolved discussion (waiting on eytan-starkware and TomerStarkware).
crates/cairo-lang-semantic/src/expr/test_data/literal line 36 at r1 (raw file):
Previously, eytan-starkware wrote…
Bad diagnostic
the location isn't very good - but the diagnostic definitely is.
orizi
force-pushed
the
orizi/03-31-fix_non_type_numeric_literal_suffix
branch
from
3395304 to
18fe653
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Replace panic with proper error handling when encountering non-type identifiers in numeric literal type suffixes. The
try_get_ty_by_namefunction now returns aSemanticDiagnosticKind::NotATypeerror instead of panicking when a type suffix is not actually a type.Type of change
Please check one:
Why is this change needed?
The compiler was panicking when encountering numeric literals with non-type suffixes (e.g.,
1_booleanwherebooleanis not a valid type). This caused the compiler to crash instead of providing a proper diagnostic message to the user.What was the behavior or documentation before?
When a numeric literal had a suffix that wasn't a valid type, the compiler would panic with a message like "boolean is not a type."
What is the behavior or documentation after?
The compiler now gracefully handles this error case by emitting a proper diagnostic error "Not a type." (error code E2011) and continues compilation instead of crashing.
Related issue or discussion (if any)
Fixes #9791
Additional context
The change includes a test case that verifies the new error handling behavior with
1_booleanas an example of a numeric literal with an invalid type suffix.Note
Medium Risk
Touches core type-resolution helper
try_get_ty_by_name, which is used broadly; while the change is limited to an error path, it can alter diagnostics and control flow for invalid code.Overview
Fixes a compiler crash when resolving numeric literal type suffixes by changing
try_get_ty_by_nameto returnSemanticDiagnosticKind::NotATypeinstead of panicking when the looked-up item exists but is not a type.Adds a regression test ensuring
1_booleanproduces errorE2011(Not a type) rather than aborting compilation.Written by Cursor Bugbot for commit 18fe653. This will update automatically on new commits. Configure here.